1. Field of the Invention
The present invention relates generally to digital data generation and communication, and, more particularly, to a method and apparatus for converting between different digital data representation formats.
2. Description of the Related Art
Certain hardware, software and networking applications send and receive digital data representing an address in varying ways, depending on the specific implementation and governing protocol. In one known canonical representation, bits (e.g., typically 8 bits) defining each byte of a typical network address are grouped into two 4-bit digits. Each digit is represented by a hexidecimal character between 0 and F, with F corresponding to a decimal value of 15. The bits are sent such that the least significant digit of the byte is sent first, followed by the most significant digit. In other words, the order of the digits that make up each byte is reversed. In a non-canonical representation, the bits of the entire address are sent in a most significant bit (MSB) to least significant bit (LSB) order, without regard to digit groupings. At the receiving end, the received bits must be interpreted, and, thus, it is necessary that the transmission algorithm being used be known to allow for the correct decoding of each digit and the whole network address.
To illustrate the two types of address communication techniques, consider the decimal number 168. Converted into a hexadecimal notation (i.e., base 16), this decimal number translates to 0xA8h, or 1010 1000 in binary. This is "MSB first," non-canonical representation of the number (i.e., MSB to LSB). In a communication system that transmits data non-canonically, the bits are transmitted in exactly this order (i.e., 1-0-1-0-1-0-0-0), and then reassembled on the receiving end. A communication system that transmits the number in a least significant digit first, canonical format reverses the order of digits (i.e., 1-0-0-0-1-0-1-0). A direct translation of the received binary pattern to hexadecimal notation yields 0x8Ah, instead of the intended 0x5lh. Accordingly, if the receiving end incorrectly assumes the transmission scheme being employed, the received address will be incorrect.
In one exemplary communication network, the Fiber Distributed-Data Interface standard (FDDI) establishes a protocol for data transmission on fiber optic lines in a local area network (LAN) where network addresses are sent and received in a MSB first, non-canonical hexadecimal representation. In contrast, the Ethernet protocol, a widely used LAN technology, sends and receives the hexadecimal address in a least significant digit first, canonical representation. Often for error tracking, problem investigation, and fault correction, log files including addresses are created. An analyst trying to trace a troublesome fault typically analyzes both FDDI and Ethernet log files. As described above, network addresses are recorded in differing formats, and the analyst typically manually converts the network addresses of one type to addresses of the other type for comparison and analysis. This conversion is time consuming, and, due to the repetitive nature of the task, error prone.
One example of the problem is illustrated by a trace file. An FDDI machine transmits a certain frame to an Ethernet machine. In the FDDI trace logs, the transmitted address is represented as the non-canonical form of the Ethernet address. However, on the Ethernet machine, the same packet is decoded and logged as if coming from a canonical source.
In network monitoring applications, data is mostly coded using a canonical representation, but the actual FDDI trace logs shows the addresses in non-canonical form. For example, the Solaris.TM. operating system, offered by Sun Microsystems, presents the FDDI media access control (MAC) address, a computer's unique hardware number, in Ethernet form, but logs the network activity in the FDDI form. This forces the system analyst to manually convert the logged addresses into Ethernet form for further manipulation, research, or other activities. As stated above, the time requirements and likelihood of human error involved in executing these translations is quite high. There are many situations, other than just those related to the interpretation of network logging and trace files, where translations between canonical and non-canonical are required.
The present invention is directed to overcoming, or at least reducing the effects of, one or more of the problems set forth above.